ETSITS132 152V7.1.0 



(2007-03) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

Telecommunication management; 

Integration Reference Point (IRP) Information Service (IS) 

Unified Modelling Language (UML) repertoire 

(3GPP TS 32.152 version 7.1.0 Release 7) 



33i^ 



GS 




® 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 





3GPP TS 32.1 52 version 7.1 .0 Release 7 1 ETSI TS 1 32 1 52 V7.1 .0 (2007-03) 



Reference 



RTS/TSGS-0532152V710 
Keywords 



GSM, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2007. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 32.1 52 version 7.1 .0 Release 7 2 ETSI TS 1 32 1 52 V7.1 .0 (2007-03) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 
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GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

TS 32.150: Integration Reference Point (IRP) Concept and definitions 

TS 32.151: Integration Reference Point (IRP) Information Service (IS) template 

TS 32.152: Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language 

(UML) repertoire 

TS 32.153 Integration Reference Point (IRP) technology specific templates 

TS 32.154 Backward and Forward Compatibility (BFC); Concept and definitions 
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1 Scope 

3GPP SA5 has chosen UML to capture systems behaviour in the IRP IS context. 

UML provides a rich set of concepts, notations and model elements to model distributive systems. Usage of all UML 
notations and model elements is not necessary for the purpose of IRP IS specifications. This TS documents the 
necessary and sufficient set of UML notations and model elements, including the ones built by the UML extension 
mechanism «stereotype», for use by 3GPP IRP IS authors. Collectively, this set of notations and model elements is 
called the 3GPP IRP IS modelling repertoire. 

The selection of the UML notations and model elements in this repertoire is based on the needs of the existing 3GPP 
IRP IS specifications. Future IRP IS releases may require the use of additional UML notations or model elements. 

IRP IS specifications shall employ the UML notation and model elements of this repertoire and may also employ other 
UML notation and model elements considered necessary. However, before any other UML notation and model elements 
may be employed in an approved 3GPP IRP specification, the other notation and model elements should be agreed for 
inclusion first in this repertoire. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[4] 3GPP TS 32.151: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) template". 

[5] OMG: "Unified Modelling Language Specification, Version 1.5". 

http://www.omg.org/technologv/documents/formal/uml.htm 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

IRPAgent: See 3GPP TS 32.150 [3]. 

IRPManager: See 3GPP TS 32.150 [3]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

GERAN GSM/EDGE Radio Access Network 

IRP Integration Reference Point 

IS Information Service 

NRM Network Resource Model 

OMG Object Management Group 

UML Unified Modelling Language (OMG) 



Requirements 



IRPAgent can be characterized by several different but related models. The models can be exterior or interior to the 
IRPAgent. Exterior models are use case models and interior models are object models. 

Current version of this TS focuses on the interior model aspects of IRP Agents. 

The notation elements captured in this repertoire shall be used to model all aspects of NRM IRP IS (such as GERAN 
NRM IRP: IS) and (interface) IRP (such as Alarm IRP: IS). 

All quotes are from [5]. 

Capitalized words are defined by various 3GPP IRP IS specifications or the reference [5]. 



£75/ 



3GPP TS 32.152 version 7.1.0 Release 7 



ETSI TS 132 152 V7.1.0 (2007-03) 



Model Elements and Notations 



5.1 



Basic model elements 



UML defined a number of basic model elements. This subclause lists the selected subset for use in the repertoire. The 
semantics of the selected ones are defined in [5]. 

• attribute (subclause 3.25 of [5]). 

This sample shows two attributes, listed as strings in the attribute compartment of the class AClass. 



«lnformationObjectClass» 
AClass 



attributeA 
attributeB 



• aggregation (subclause 3.43.2.5 of [5]). 

This sample shows a hollow diamond attached to the end of a path to indicate aggregation. The diamond is attached to 
the class that is the aggregate. 



«lnformationObjectClass» 

ManagedElement o^ 



«lnformationObjectClass» 
-^ MscFunction 



• operation (subclause 3.26 of [5]). 

This sample shows two operations, shown as strings in the operation compartment of class AClass, that the instance of 
AClas s may be requested to perform. The operation has a name, e.g. operationA and a list of arguments (not shown). 



«lnformationObjectGlass» 
AClass 

operationAO 
operationBO 



• association, association name (subclause 3.41 of [5]). 

This sample shows a binary association between exactly two model elements. The association can include the 
possibility relating a model element to itself This sample shows a bi-directional association in that one model element 
is aware of the other. Association can be unidirectional (shown with an open arrow at one association end) in that only 
the source model element is aware of the target model element and not vice-versa. 



«lnformationObjectClass» 
AClass 





«lnfornnationObjectClass» 
BCIass 









• realization relationship (subclause 2.5.2. 1 of [5]). 

This sample shows the realization relationship between a AlarmlRPNotif ication_l (the supplier) and a model 
element, IRPManager, that implements it. 
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«lnformationObjectClass» 
IRPManager 



[>- 



«lnterface» 
AlarmlRPNotification 1 



• generalization relationship (subclause 3.50 of [5]). 

This sample shows a generalization relationship between a more general element (the IRP Agent) and a more specific 
element (the IRPAgent_vendor_A) that is fully consistent with the first element and that adds additional 
information. 



«lnformationObjectClass» 
IRPAgent 



<^ 



«lnformationObjectClass» 
IRPAgent_vendor_A 



• dependency relationship (subclause 3.51 of [5]). 

This sample shows that BClass instances have a semantic relationship with AClass instances. It indicates a situation 
in which a change to the target element will require a change to the source element in the dependency. 



«lnformationObjectClass» 

AClass < 



«lnformationObjectClass» 
BClass 



• note (subclause 3.11 of [5]). 

This sample shows a note, as a rectangle with a "bent corner" in the upper right comer. The note contains arbitrary text. 
It appears on a particular diagram and may be attached to zero or more modelling elements by dashed lines. 



«lnformatlonObjectClass» 
SubNetwork 



This is a sample of 
a note. 



• Multiplicity, a.k.a. cardinality (subclause 3.44 of [5]). 

This sample shows a multiplicity attached to the end of an association path. The meaning of this multiplicity is that one 
Network instance is associated with zero, one or more SubNetwork instances. 



«lnformationObjectClass» 
Network 



«lnformationObjectClass» 
SubNetwork 



0..* 



• rolename (subclause 3.43.2.6 of [5]). 

This sample shows a Person (say instance John) is associated with a Company (say instance XYZ). We navigate the 
association by using the opposite association-end such as John.theCompany ="XYZ". Use noun for the rolename. 



Company 



<e 



Person 



+theCompany 
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5.2 Stereotype 



This subclause defines all allowable stereotypes that are summarized in the following table. Except «Interface», 
«Type» and «use» (which are defined in [5]), all other stereotypes are extensions specifically designed for use in 
IRP IS specifications. 

Table: Stereotypes 



Stereotype 


Base Class 


Affected Metamodel Elements 


Interface 


Class 




Type 


Class 




ProxyClass 


Class 




Notification 


Class 




Archtetype 


Classifier (subclause 2.5.2.10 of [5]) 




InformationObjectClass 


Classifier 




use 


Association 




may use 


Association 




may realize 


Association 




emits 


Association 




names 


Composition 


-- 


opt (alternatively «optional») 


IVIodelElement 


Attribute, Parameter, and Operation 


% 


SGPPVisibilityKind 


-- 
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5.2.1 «lnterface» 

Subclause 2.5.2.25 of [5]: 

"An interface is a named set of operations that characterize the behaviour of an element. In the metamodel, an Interface 
contains a set of Operations that together define a service offered by a Classifier realizing the Interface. A Classifier 
may offer several services, which means that it may realize several Interfaces, and several Classifiers may realize the 
same Interface. 

Interfaces may not have Attributes, Associations, or Methods. An Interface may participate in an Association provided 
the Interface cannot see the Association; that is, a Classifier (other than an Interface) may have an Association to an 
Interface that is navigable from the Classifier but not from the Interface." 

Subclause 2.5.4.6 of [5]: "The purpose of an interface is to collect a set of operations that constitute a coherent service 
offered by classifiers. Interfaces provided a way to partition and characterize groups of operations. An interface is only 
a collection of operations with a name. It cannot be directly instantiated. Insatiable classifiers, such as class or use case, 
may use interfaces for specifying different services offered by their instances. Several classifiers may realize the same 
interface. All of them must contain at least the operations matching those contained in the interface. The specification of 
an operation contains the signature of the operation (i.e. its name, the types of the parameters and the return type). An 
interface does not imply any internal structure of the realizing classifier. For example, it does not include which 
algorithm to use for realizing an operation. An operation may, however, include a specification of the effects [e.g. with 
pre and post-conditions] of its invocation." 



5.2.1.1 



Sample 



This sample shows an AlarmIRPOperations_l «Interface» that has two operations. The operation visibility is 
public (see definition of public visibility applicable to operation in subclause "visibility"). The input and output 
parameters of the operations are hidden (i.e. not shown). The AlarmlRP has a unidirectional mandatory realization 
relationship with the «Interface». 



«lnformationObjectClass» 
AlarmlRP 



«lnterface» 
AlarmlRPOperations_1 



-[>= 



getAlarmListO 
acknowledgeAlarmsQ 



«lnterface» Notation 
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5.2.2 «Type» 



Subclause 3.28 of [5]: "[A Type is] a domain of objects together with the operations applicable to the objects, without 
defining the physical implementation of those objects. A Type may not contain any methods, maintain its own thread of 
control, or be nested. However, it may have Attributes and Associations. The Associations of a Type are defined solely 
for the purpose of specifying the behaviour of the Type's operations and do not represent the implementation of state 
data". 



5.2.2.1 



Sample 



This sample shows the NotificationlRPNotification «Type» that specifies the five parameters (the notification header 
of Notification IRP). The AlarmlRPNotif ication_2 «Interface» depends (see the dependency relationship, a 
dashed open arrow line) on this «Type» for the construction of the notification emitted via the operation 
notifyChangedAlarm(). The visibility of attributes and operation in the example is public. 



«Type» 
NotificationlRPNotification 

+ objectClass 
+ objectlnstance 
+ notificationid 
+ eventlime 
+ systemDN 
+ notificationType 



«lnterface» 
AlarmlRPNotification_2 

+ notifyChangedAlarmO 



«Type» Notation 
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5.2.3 «ProxyClass» 

It is a form or template representing a number of «InformationObjectClass». It encapsulates attributes, links, 
methods (or operations), and interactions that are present in the represented «InformationObjectClass». 

The semantics of a «ProxyClass» is that all behaviour of the «ProxyClass» are present in the represented 
«InformationObjectClass». Since this class is simply a representation of other classes, this class cannot define its 
own behaviour other than those already defined by the represented «InformationObjectClass». 

A particular «InformationObjectClass» can be represented by zero, one or more «ProxyClass» or 
«Archetype». For example, the ManagedElement «InformationObjectClass» can have MonitoredEntity 
«ProxyClass» and ManagedEntity «ProxyClass». 

The attributes of the «ProxyClass» are accessible by the source entity that has an association with the 
«ProxyClass». 



5.2.3.1 



Sample 



This shows a «ProxyClass» named MonitoredEntity. It represents all NRM «InformationObjectClass» 
(e.g. GgsnFunction «InformationObjectClass») whose instances are being monitored for alarm conditions. 

Note that «MonitoredEntity» does not define attributeA. The attributeA is already defined by all 
«InformationObjectClass» represented by the «MonitoredEntity», i.e. ClassA and ClassB. 



«ProxyClass» 
MonitoredEntity 
+ attributeA 



«lnformationObjectClass» 
ClassA 



+ attributeA 
+ attributes 
+ attributeX 
+ attributeY 



«lnformationObjectClass» 
ClassB 



+ attributeA 
+ attributes 
+ attributeC 



«ProxyClass» Notation Sample 1 

See Annex A for more samples that use «ProxyClass». 
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5.2.4 «Archetype» 

It is a form or template representing a number of «InformationObjectClass». It encapsulates attributes, links, 
operations, and interactions that are typical of the represented «InformationObjectClass». 

The semantics of an «Archetype» is that all attributes, links operations and interactions encapsulated by the 
«Archetype» may or may not be present in the represented «InformationObjectClass». The «Archetype» 
represents a placeholder class that is most useful in technology neutral analysis models that will require further 
specification and/or mapping within a more complete construction model. 

5.2.4.1 Sample 

This shows a «Archetype» named StateManagement. It also shows a «InformationObjectClass» IRP Agent that 
depends on this StateManagement. Note that the StateManagement has defined a number of attributes, the classes that 
depend on this StateManagement may or may not use all of the StateManagement attributes. In other words, at least one 
of the attributes of StateManagement is present in the IRP Agent. The precise set of StateManagement attributes used 
by the IRP Agent is specified in the IRP Agent specification. 

«Archetype» 
StateManagement «lnfornnationObjectClass» 

+ adnninistrativeState < IRPAgent 



+ otherStates 



«Archetype»> Notation 



5.2.5 «lnformationObjectClass» 



It is the descriptor for a set of network resources and network management capabilities. Each 
«InformationObjectClass» represents a set of instances with similar structure, behaviour and relationships. 

This «InformationObjectClass» and other information classes such as «Interface» are mapped into technology 
specific model elements. The mapping of IS modelling constructs to technology specific modelling constructs are 
captured in the corresponding IRP Solution Set specifications. 

The name of a «InformationObjectClass» has scope within the 3GPP IRP IS document in which it is specified and 
the name must be unique among all «InformationObjectClass» names within that 3GPP IRP IS document. The IRP 
IS document name is considered in the similar way as the UML Package-name. 

The «InformationObjectClass» is identical to UML class except that it does not include/define methods or 
operations. 

Subclause 3.22.1 of [5]: "A class represents a concept within the system being modelled. Classes have data structure 
and behaviour and relationships to other elements." 

5.2.5.1 Sample 

This sample shows an AlarmList «InformationObjectClass». 

«lnformationObjectClass» 
AlarmList 

- attributel 

- otherAttributes 



«lnformationObjectClass»> Notation 
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5.2.6 «use» and «may use» 

The «use» and «may use» are unidirectional associations. The target must be an «Interface». The «use» 
states that the source class must have the capability to use the target «Interface» in that it can invoke the operations 
defined by the «]iiterface». Support of the capability by the source entity is mandatory. The «may use» states that 
the source class may have the capability to use the target «Interface» in that it may invoke the operations defined by 
the «Interface». Support of the capability by the source entity is optional. 

The operations defined by the «Interface» are visible across the Itf-N. 



5.2.6.1 



Sample 



This shows that the NotificationIRP Agent shall use the notif yNewAlarm and notifyChangedAlarm of 

AlarmlRPNotif ication_l and may use the notifyChangedAlarm of AlarmlRPNotif ication_2. 



«lnfornnationObjectClass» 
NotificationIRP Agent 



«use» 



«lnterface» 
AlarmlRPNotification 1 



<<<mayuse» 



->- 



+ notifyNewAlarmO 
+ otlierNotificationsQ 



«lnterface» 
AlarmlRPNotification 2 



+ notifyChangedAlarmO 



«use» and «may use» Notation 
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5.2.7 Relationship realize and «may realize» 

The relationship realize and «may realize» are unidirectional association. The target must be an «Interface». The 
relationship "realize" shows that the source entity must realize the operations defined by the target «Interface». 
Realization of operations by the source entity is mandatory. The «may realize» shows the source entity may realize 
the operations defined by the target «Interface». Realization of the «Interface» by the source entity is optional. 

The operations defined by «Interface» are visible across the Itf-N. 



5.2.7.1 



Sample 



This shows that the AlarmList shall realize (or support, implement) the two operations of 
AlarmIRPOperations_l and may realize the operation of AlarmIRP0perations_2. 



«lnterface» 
Alarm IRPOperations_1 

+ getAlarmList() 

+ acknowledgeAlarmsQ 



«lnformationObjectClass» 
AlarmList 



attributel 
otherAttributes 



<<mayrealize» 

«lnterface» 
Alarm IRPOperations_2 

+ getAlarmCountO 

Relationship realize and «may realize» Notations 
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5.2.8 «emits» 

This is a unidirectional association. The source sends information to target. In the case that the target is 
NotificationIRP Agent, the information will then carry the semantics of 3GPP notification (e.g. 
notif yOb jectCreation, notif yNewAlarm) such that the target Notif icationlRPAgent can construct 
the relevant 3GPP notification for reception by the IRPManager. 

The visibility of the information passed by «emits» is always "IRP Agent Internal" (see subclause on "Visibility"). 



5.2.8.1 



Sample 



This shows the MonitoredEntity (e.g. a GgsnFunction instance) emits notifications that are received by the 
Notif icationlRPAgent. The emission is not visible across the Itf-N. 



«ProxyClass» 
MonitoredEntity 



«emlts» 



-> 



«lnformationObjectClass» 
Notification IRPAgent 



«emits» Notation 



«ProxyClass» 
MonitoredEntity 

objectclass 
objectlnstance 



«emits» 



-> 



«lnterface» 
AlarmlRPNotification 1 



+ notifyNewAlarmQ 
+ otherOperationsO 



«use»/ 



«lnformationObjectClass» 
NotificationlRPAgent 



«lnformationObjectClass» 
IRPManager 



«use», «emits» and realize relationship Notation 
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5.2.9 «names» 

It specifies a unidirectional composition. The target instance is uniquely identifiable, within the namespace of the 
source entity, among all other targeted instances of the same target classifier and among other targeted instances of 
other classifiers that have the same «names» composition with the source. 

Composition used as the act of name containment provides a semantic of a whole-part relationship between the domain 
and the named elements that are contained, even if only by name. From the management perspective access to the part 
is through the whole. Multiplicity shall be indicated on both ends of the relationship. 

A target can not have multiple «names» with multiple sources, i.e. a target can not participate in or belong to 
multiple namespaces. 

By convention, the name of the attribute in the target model element to hold part of the unique identification shall be 
formed by the name of the target class concatenated with "Id". There are two presentation options for the unique 
identification attribute of the class being named. 

1) The use of the role qualifier allow the unique identification attribute to be attached to the target end of the 
«names» association (see the following figure). 

2) The unique identification attribute may be indicated as a normal attribute within the class attribute compartment. 

5.2.9.1 Sample 

This shows that all instances of ManagedFunction are uniquely identifiable within the ManagedElement 
namespace. Note the use of the label supports in specifications is optional. 



ManagedElement 



«names» 

ManagedFunction 
managedFunctionId 



supports 

0.. 



«names» Notation, Composition and explicit Qualifier 



5.2.10 «opt» 

The «opt» (alternatively «optional») enables the indication of optionality of attributes, parameters and operations 
(respectively) within the UML diagrams. The semantics of optionality are clearly defined in TS 32.150 [3]. 

In the absence of the stereotype, the attribute, parameter, or operation in question is mandatory. 



« lnterface» 
BulkCMActive 



+ downloadO 
«opt» + validateO 
«opt» + preactivateO 
+ activateO 
+ fallbackO 



Example of the use of optionality indicator for operations 
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5.2.11 



«Notification» 



«Notification» is a named set of notifications. In the metamodel, a «Notification» contains a set of Notifications 
that together define a service offered by a Classifier reahzing the «Notification». 

5.2.11.1 Sample 

This sample shows a «Notification» named "PMIRPNotif ications_l" that has one notification and a 
«Notification» named "PMIRPNotif ications 2" that has three notifications. 



«lnformationObjectClass» 
NotificationIRP 

(from TS 32.302) 



«agent-internal-usage» 



«Notification» 
PMIRPNotifications 1 



- notifyMeasurementJobStatusChangedO 




«agent-internal-usage» 



«lnformationObjectClass» 
PMIRP 



«rr)ay use» 




«Notification» 
PMIRPNotifications_2 

- notifyThresholdMonitorStatusChangedO 

- notifyThresholdMonitorObjectCreationO 

- notifyThresholdMonitorObjectDeletionO 



5.3 Visibility 



It specifies the accessibility of the operation and attribute. There are three types of visibiUty, i.e. private, public and 
IRP Agent Internal. 



Private Visibility (notation "-") 



Operation 



NA 



Attribute 



It indicates that the attribute is not accessible by other entities, e.g. the IRPManager, other entities not 
holding the subject attribute 



Public Visibility (notation "+")(default) 



Operation 



It indicates that the operation is visible across the Itf-N, e.g. the IRPManager can invoke the operation 
across the Itf-N interface. 



Attribute 



it indicates that the attribute is accessible across the Itf-N, i.e. the IRPManager can invoke an 
operation to read the attribute and to write to this attribute if the attribute is so qualified. The read or 
write operation must be directly invoked against the entity holding the subject attribute or against the 
IRPAgent. 



IRPAgent Internal Visibility (notation "%") 



Operation 



It indicates that the operation is not visible across the Itf-N, i.e. the IRPManager cannot invoke the 
operation. However, other entities can invoke the operation (see note). 



Attribute 



It indicates that the attribute is not directly accessible across the Itf-N, i.e. the IRPManager cannot 
read/write this attribute. However, other entities can read/write this attribute. 



ETSI 



3GPP TS 32.152 version 7.1.0 Release 7 



19 



ETSI TS 132 152 V7.1.0 (2007-03) 



5.3.1 Samples 



This sample shows four attributes whose visibility are private, public (default notation), public and IRP Agent Internal. 
It is recommended that within a Class symbol, the use of default notation or not for public visibility should be 
consistent, i.e. all "publicly visible" attributes shall be shown with the "+" sign or without the "+" sign (default 
notation). 



« Information Object Class » 
ClassSample 

- attribute A 
attributes 
attributeC 
«%»attributeD 



Visibility of attributes 

This sample shows three operations. Two of these operations are accessible by the IRPManager via the Itf-N. It is 
recommended that within a Class symbol, the use of default notation or not for public visibility should be consistent, 
i.e. all "publicly visible" operation shall be shown with the "+" sign or without the "+" sign (default notation). 



«lnterface» 
InterfaceSample 

+ operationAQ 
+ operationBQ 
«%» operationCQ 



Visibility of operations 

This sample shows one notification whose visibility is public using the non-default public visibility notation. These 
notifications are accessible by the IRPManager via the Itf-N. 



«lnterface» 
AlarmlRPNotification 2 



+ notifyChangedAlarmQ 



Visibility of notification 
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5.4 



Association classes 



Subclause 3.46 of OMG: "Unified Modelling Language Specification, Version 1.51" [5] 
http ://w WW. omg . org/technolo g y/documents/formal/uml. htmd defines an association class as 

"An association class is an association that also has class properties (or a class that has association properties). 
Even though it is drawn as an association and a class, it is really just a single model element.". 

Association classes are appropriate for use when an «InformationObjectClass» needs to maintain associations to several 
other «InformationObjectClass»'s and there are relationships between the members of the associations within the scope 
of the "containing" «InformationObjectClass». For example, a namespace maintains a set of bindings, a binding ties a 
name to an object. A Binding «IOC» can be modeled as an Association Class that provides the binding semantics to the 
relationship between a name and some other «InformationObjectClass». This is depicted in the following figure 
(exemplary only, not taken from another 3GPP specification). 



<<lnfoimationObjectClass» 
Namespace 



0..* 



<<lnfoimationObjectClass» 
Binding 



Name 



<< Inform at ion ObjectClass>> 
Object 



Example of an Association Class 
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5.5 Abstract Class 

It specifies a «InformationObjectClass» as a base class to be inherited by subclasses. An abstract class can not be. 

Abstract class notation is the use of italics in the class name of the corresponding «InformationObjectClass» in the 
diagram. 

5.5.1 Sample 

This shows that ManagedGenericIRP is an abstract «InformationObjectClass». 



«lnformationObjectClass» 
Managec/Gener/c/nP 



(from 32.312) 



«lnformationObjectClass» 
NotificationIRP 

(from 32.302) 



Abstract Class Notation 
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Annex A (informative): 

Samples of using «ProxyClass» to model Link related 

IOCS 

A.1 First Sample 

This shows a «ProxyClass» named YyyFunction. It represents all lOCs listed in the Note under the UML diagram. 
All the listed lOCs, in the context of this sample, inherit from ManagedFunction IOC. 

The use of «ProxyClass» eliminates the need to draw multiple UML «InformationObjectClass» boxes, i.e. those 
whose names are listed in the Note, in the UML diagram. 

«lnformationObjectClass» 
ManagedFunction 

(from TS 32.622) 



«ProxyClass» 
YyyFunction 



Note: The YyyFunction «ProxyClass» represents As Function, AucFunction, BgFunction, 

«ProxyClass» Notation Sample A.I 



A.2 Second Sample 



This shows a «ProxyClass» named YyyFunction. It represents all lOCs listed in the Note right under the UML 
diagram. All the Usted lOCs, in the context of this sample, have link (internal and external) relations. 

The actual names of the IOC represented by InternalYyyFunction «ProxyClass» and by the ExternalYyyFunction 
«ProxyClass» are listed under the subsection of X. Y of the associated YyyFunction. For example, under X.Y. 1 for 
AsFunction, two paragraphs are added to list all peer internal entities and external entities that are linked with 
AsFunction. See sample in quotation below that is using AsFunction as a sample for YyyFunction. 
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The actual names of the IOC represented by Link_a_z «ProxyClass» and by ExternalLink_a_z «ProxyClass» are 
listed under the subsection of X. Y of the associated YyyFunction. For example, under X. Y. 1 for AsFunction, two 
paragraphs are added to list the names of the lOCs represented by Link_a_z and by ExternalLink_a_z. See the quoted 
text below that is using AsFunction as a sample for YyyFunction. 



X.Y.1 



AsFunction 



X.Y.1. 1 Definition 

This IOC represents As functionality. For more information about the As, see 3GPP TS 23.002 [15]. 

The linked InternalYyyFunction «ProxyClass» represents SlsFunction, CscfFunction, HlrFunction , 

The linked ExternalYyyFunction «ProxyClass» represents . . . 

The Link_a_z «ProxyClass» represents Link_As_Scscf, Link_Bgcf_Scscf ... 

The ExternalLink_a_z «ProxyClass» represents . . . 



«ProxyClass» 
Link a z 



«ProxyClass» 
ExtemalLink a z 



«ProxyClass» 
InternalYyyFunction 




«ProxyClass» 
YyyFunction 




«ProxyClass» 
ExtemalYyyFuntion 



















NOTE: The 'Yyy' of YyyFunction «ProxyClass» represents AsFunction, AucFunction, ... 

«ProxyClass» Notation Sample A.2 
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Annex B (informative): 
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